Skip to content

_settings_lock ensures only one thread can execute transient_settings…#289

Merged
lirshindalman merged 2 commits intomasterfrom
fix_secret_iac_parallel
Feb 25, 2026
Merged

_settings_lock ensures only one thread can execute transient_settings…#289
lirshindalman merged 2 commits intomasterfrom
fix_secret_iac_parallel

Conversation

@lirshindalman
Copy link

File changed: detect_secrets/settings.py

Added threading.Lock (_settings_lock) - serializes access to transient_settings() so only one thread can modify/clear the global caches at a time, eliminating the race window.

Added get_mapping_from_secret_type_to_class.cache_clear() to cache_bust() - ensures any stale plugin-type mapping built from empty settings is always invalidated when caches are cleared.

Impact
No API changes — transient_settings() and cache_bust() signatures are unchanged
No performance impact on single-threaded usage — uncontended lock acquisition is ~50ns
Fixes concurrent usage — multiple threads calling transient_settings() will now serialize correctly instead of corrupting shared state
Backward compatible — the lock only adds safety; existing single-threaded callers are unaffected

lshindelman added 2 commits February 23, 2026 16:15
…() at a time, eliminating the window where get_settings() returns empty Settings()

Adding get_mapping_from_secret_type_to_class.cache_clear() to cache_bust() ensures any stale plugin mapping cached during a race window is always invalidated
@lirshindalman lirshindalman merged commit b84459a into master Feb 25, 2026
2 of 20 checks passed
@lirshindalman lirshindalman deleted the fix_secret_iac_parallel branch February 25, 2026 10:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants